\chapter{Réalisation de l'application}

\section{Choix technologiques}

\subsection{Travail collaboratif}

Pour travailler de façon conjointe sur le code d'un même projet, nous avons
choisi d'utiliser SVN (SubVersioN)\footnote{Subversion est un système de
gestion de versions centralisé permettant entres autres de travailler à
plusieurs sur un même projet.}. Nous nous sommes tournés vers \emph{Google Code}
qui propose un service de stockage de codes sources et un système de gestion de
versions de type SVN.

\subsection{Langage de programmation}

Le système doit-être modulaire et réutilisable. Les délais nous poussent à
choisir un langage de programmation orienté objet répondant aux différentes
exigence. C'est donc le langage \textbf{JAVA} qui est choisi.

\subsection{Stockage des données}
L'application doit manipuler un grand nombre de données et y accéder
très fréquemment. Pour répondre à ce besoin notre choix s'est tourné
vers un système de gestion de base de données relationnelle :
\textbf{PostgreSQL}. 

\subsection{Mapping Objet / Relationnel}


Pour sauvegarder l'état de nos objet JAVA dans la base de données il existe
plusieurs solutions. La première consisterait à utiliser l'API JDBC, connue.
Une autre solution, plus efficace et plus modulaire consiste à utiliser un
framework ORM (Object Relationnal Mapping). Cette seconde solution nous mènera
à comprendre le fonctionnement de ce type de framework et à le mettre en
place. Nous ne sommes pas assurés que la rapidité de mise en place d'un tel
framework compense son apprentissage. Néamoins l'aspect académique de ce
projet nous pousse à opter pour l'utilisation de ce type de framework.
Ainsi, notre choix s'est tourné sur la spécification
\textbf{JPA} et de son implantation \textbf{EclipseLink}.

\subsection{Autres technologies JAVA}

Pour rendre l'application plus modulaire et plus réutilisable, nous utilisons
des technologies propres à JAVA dont la liste est la suivante :

\begin{description}
\item[Journalisation] : La gestion des \emph{logs}\footnote{Un logger permet de
gérer la journalisation des évènements d'une application et de leur attribuer
un niveau (informatif, debug, problème\ldots). Les logs peuvent-être stoquées
sur un fichier, redirigés sur la console ou bien sur une \emph{socket}.} est
réalisée avec le \emph{Logger du JDK Java}. Celui-ci permet de retracer les
différents échanges avec les base de données. Les journaux permettent d'avoir
des informations sur les connexions à l'application, sur les opérations
d'ajout / suppression ainsi que sur d'autres points.
\item[Internationnalisaton] : L'internationnalisation de l'application est
réalisé grâce à la classe \emph{ResourceBundle}. 
\end{description}

\subsection{Echange de données à distance}

Les données intrinsèques à l'emploi du temps doivent pouvoir être facilement
exportées et importées pour des traitement externes à ceux réalisés par
l'application. Pour répondre à cette exigence, le langage \textbf{XML} s'impose.

\subsection{Publication de données sur le WEB}

Pour la publication des données sur le WEB, nous devons nous dôter d'un outil
capable d'interroger un SGBDR, de traiter des documents XML et de les
transformer pour les publier sous le format HTML ou encore PDF. Pour cela nous
utiliserons \textbf{Apache Cocoon} qui est un framework basé sur Spring
et utilisant le langage \textbf{XSLT} (Extensible Stylesheet Language
Transformations) pour la transformation des documents XML.

\emph{Cocoon} en quelques mots : 

\begin{description}
  \item[Sitemap] C'est la partie la plus importante, puisque c'est elle qui
  décrit la configuration du site WEB et les interractions client - serveur.
  C'est dans le sitemap que sont décrites les différentes transformations
  appliquées aux documents XML. En fonction des documents que l'on veut générer
  (HTML,PDF, etc.), les transformations seront différentes.
  \item[Pipelines]  Ils définissent la façon dont une source va être transformée
  pour fournir un document. Ils sont en général constitués  d'un
  générateur, d'un ou plusieurs transformateurs et d'un sérialiseur.
  \item[Générateurs] Ils générent des évènements SAX\footnote{Simple API for
  XML (SAX) est une API évènementielle pour analyser syntaxiquement un flux XML}
  à partir de sources pouvant être des documents XML ou des données issues d'une BDR, d'une image etc.
  \item[Transformateurs] Ils transforment les évènements SAX reçus par le
  générateur et appliquent généralement une feuille de style
  XSLT\footnote{eXtensible Stylesheet Language Transformations (XSLT)} qui
  transformera le document XML en un autre document XML.
  \item[Sérialiseurs] Ils permettent de founir à l'utilisateur le document
  souhaité. Celui-ci peut être un document XML, un fichier binaire
  représentant par exemple un document PDF ou une image au format JPEG.
\end{description}

\begin{figure}[!ht]
\includegraphics[scale=0.5]{img/cocoon.eps}
\caption{Schéma d'explication Cocoon}
\end{figure}

\section{Architecture de l'application}

L'architecture de l'application a été pensée pour être modulaire et
réutilisable. Elle se base ainsi sur quatre couches : 

\begin{figure}[!ht]
	\begin{center}
	\begin{tabular}{|c|}
	\hline
	Présentation  \\
	\hline
	Services \\
	\hline
	Métier \\
	\hline
	Accès aux données\\
	\hline
	\end{tabular}
	\end{center}
	\caption{Modèle d'application en quatre couches}
\end{figure}


\begin{description}
\item[Couche d'Accès aux données (DAO)\footnote{Data Access Object}] : C'est la
couche permettant de faire la relation entre les données stockées dans un contexte persistant (ici une base
de données) et les objets Java. \emph{Dans notre projet, cette couche se
matérialise par l'implantation du framework JPA et des classes de manipulation
des entités}.
\item[Couche Métier] : C'est la couche contenant la définition des données
traitées ainsi que les traitements métiers qui leur sont associés.\emph{Dans
notre projet, cette couche se matérialise par ce que l'on a nommé l'API. La
représentation d'un enseignant, d'une promotion ou bien d'un évènement font
partie de cette API}
\item[Couche Services] : Cette couche regroupe les services qui seront
proposés par le système. Elle propose des actions de haut niveau qui
fourniront un résultat observable pour l'utilisateur. Elle permet donc de
simplifier et de contrôler l'utilisation de l'API. \emph{Dans notre
application, cette couche se matérialise par le manageur de haut niveau
SuperplanningManager. Il propose des actions telles que l'enregistrment d'une
entité, la programmation d'un cours, la récupération des salles libres pour une
période donnée etc.}
\item[Couche Présentation] : Cette couche, est
celle qui est la plus proche de l'utilisateur final puisque c'est elle qui
contiendra l'IHM. Cette couche utilise généralement le patron de construction
\textbf{MVC} (Modèle - Vue - Contrôleur). Nous détaillerons notre implantation
de ce patron de construction juste après. \emph{Dans notre application, cette
couche se matérialise par une présentation en Java pour la partie
Administration et une présentation sous forme de pages Web générées par le
serveur Cocoon pour la visualisation des emplois du temps)}
\end{description}

\subsection{Patrons de constructions utilisés}

\emph{Certains patrons étant longs à implanter, ceux-ci ne l'ont été que sur
certaines parties de l'application.}

\subsubsection{MVC \& Observeur / Observé}

C'est le patron de construction principal de l'application. Celui-ci permet une
grande modularité et un fort découplage entre les vues et les données
manipulées. Ce patron utilise le modèle Observeur / Observé. Ce dernier consiste
à rendre un objet observable (la classe de cet objet hérite alors de \textbf{Observable})
puis à faire implanter l'interface \textbf{Observer} par l'objet qui sera
observateur. Dans notre cas, les objets observables sont principalement les
données (un enseignant, une salle de cours\ldots) et les observateurs sont les
vues.
Un schéma vaut mieux qu'un long discours :

\begin{figure}[!h]
\includegraphics[scale=0.47]{img/mvc.eps}
\caption{Implantation du modèle MVC}
\end{figure}

\subsubsection{Strategy}

Ce patron consiste à isoler les parties qui sont susceptibles d'évoluer. Dans
notre application nous aurions pu créer une classe pour chaque type de personne
(Doctorant, Maître de conférence, Professeur, ATER\ldots). Concrètement nous
aurions alors utilisé l'héritage. Imaginez le nombre de classes et les niveaux
d'héritage si nous souhaitions modéliser tous les types de personne d'une
université\ldots
Une solution élégante consiste à remplacer ces héritages par une association.
Une personne a alors un comportement spécifique correspondant à son type. Il est
alors aisé de créer de nouveaux types de personne voire de modifier en cours
d'exécution le type d'une personne. 

\subsubsection{Façade}

Il est utilisé pour consituer la couche \emph{Services} de l'application. Il
permet de simplifier et de regrouper dans une façade une vue simplifiée et contrôlée des
actions qu'il est possible de réaliser sur les données. Concrètement ce patron
est représenté par une interface fournissant des services de haut niveau. Les
implantations de cette interface peut différer, pour proposer par exemple une
interaction sur des données au format XML ou des donnnées stockées dans une base
de données.

\subsubsection{Singleton}

Il consiste à contrôler l'instance d'une classe pour s'assurer qu'à tout
moment il n'existe qu'une seule instance de cette classe. Concrètement ce
patron rend privé ses constructeurs et propose une méthode \emph{getInstance()}
permettant de retourner à l'appelant l'unique instance (qui sera créée si elle
n'existe pas).

\subsubsection{D'autres patrons}

D'autres patrons ont été utilisés directement ou indirectement comme le patron
\textbf{Factory} qui est utilisé par la couche \emph{DAO} pour gérer les entités
persistantes (qui peuvent être matérialisées de différentes façons).

\section{De la modélisation à l'implantation}

Maintenant que le modèle est réalisé et que l'architecture générale de
l'application est posée nous  pouvons passer au développement. Celui-ci se
voudra le plus proche possible du modèle UML.

\subsection{Réalisation du squelette de l'application}

C'est la première étape de l'implantation. Celle-ci calque complètement sur le
modèle UML. Elle se compose des phases suivantes :

\begin{itemize}
  \item Création de l'arborescence générale (paquetage) en relation avec celles
  présentées dans l'axe statique ; 
  \item Création des classes (abstraites \& concrètes) et des interface ;
  \item Création des attributs qui deviennent des variables d'instances ;
  \item Création des méthodes .
\end{itemize}

\subsection{Réalisation des méthodes des classes métiers}

Les diagrammes d'interractions nous permettent d'écrire le corps des méthodes.
Les différents messages échangés entre les différents objets permettent
d'obtenir une grande partie des instructions qu'une méthode devra réaliser.

\subsection{Réalisation des fonctionnalités du système}

Cette partie consiste à implanter les fonctionnalités décrites dans l'axe
fonctionnel\ref{axe_fonctionnel}. Ces fonctionnalités seront traduites en
méthodes de classes. L'axe statique\ref{axe_statique} informe de la classe dans
laquelle écrire la méthode. Les fonctions présentées dans l'axe fonctionnel sont des fonctions de haut niveau
se trouvant dans la plupart du temps dans une façade. 

Cette partie est longue car elle demande de réaliser les points suivants :

\begin{itemize}
  \item Réaliser les fonctions métiers de bas niveau sur les beans.
  \item Réaliser la couche DAO ;
  \item Implanter les fonctionnalités dans les différentes façades.
\end{itemize}

\section{Choix d'implantation}

\emph{Ne le cachons pas, ce projet est long. Il pourrait même devenir un projet
industriel dont la réalisation s'étalerait sur plusieurs mois ! De plus, nous
devons partager notre temps entre les différentes matières du Master. C'est
pourquoi nous avons fait certains choix d'implantation que nous décrirons ici.
Cette partie est à lire en parallèle avec la modélisation UML.}
\newline

\begin{figure}[!ht]
	\begin{tabular}{|p{4cm}|p{9cm}|}
	\hline
	API (beans) & \textbf{implantée} \\
	\hline
	Persistence avec JPA & \textbf{implantée} \\
	\hline
	Module de connexion à la base de données & \textbf{implantée} \\
	\hline
	Sécurisation de la connexion & \textbf{implantée} : le processus
	d'authentification est délégué à la base de donnée qui contient les
	informations de connexion hachées au format MD5
	\\
	\hline
	Modèle MVC & \textbf{implantée} \\
	\hline
	IHM (Administration) & \textbf{implantée} : Utilisation de \emph{NetBeans}
	pour sa réalisation. \\
	\hline
	IHM (Visualisation) & \textbf{implantée} avec un framework de développement
	Web (\emph{Apache Cocoon}) basé sur un serveur web (\emph{Apache}) et un
	conteneur d'application (\emph{Spring})\\
	\hline 
	Administration des données (opérations CRUD sur les beans) & \textbf{implantée}
	\\
	\hline
	Programmation d'un évènement (cours) & \textbf{implantée} \\
	\hline
	 Gestion des contraintes &
	\textbf{implantée en partie} : L'API contenant les modèles de contraintes a
	été implantéee mais pour l'applicationfinale, seules les contraintes relatives
	aux disponibilités des salles a été implantée.\newline
	\emph{\underline{Raison} : Manque de temps.} \\
	\hline 
	Visualisation des emplois du temps des formations & \textbf{implantée} \\
	\hline
	Visualisation des disponibilités des salles & \textbf{Implanté} \\
	\hline
	Visualisation des emplois du temps des enseignants & \textbf{Implanté}\\
	\hline
	Gestion des filtres (administration \& visualisation) & \textbf{Non implanté}
	\newline
	\emph{\underline{Raison} : Cette partie ne comporte pas de difficulté majeure
	mais demande beaucoup de temps pour la mise en place.} \\
	\hline
	\end{tabular}
		caption{Tableau des fonctionnalités implantées}
\end{figure}
	
	
	\underline{Remarques} : Certaines fonctionnalités n'ont pas pu être implantées
	mais celles-ci ont été mûrement réfléchies lors de la phase d'analyse et de
	conception. Aussi leurs implantations ne poseront pas de problèmes d'ordre
	technique mais demanderont simplement du temps relativement conséquent.
	
	\pagebreak[9]
	
	\section{Résultat final}
	
	Nous allons maintenant présenter quelques captures d'écran concernant le
	résultat final qui a été atteint. \textbf{Nous avons fait le choix de ne
	présenter que certaines parties de l'application pour ne pas surcharger le
	rapport.}
	
\begin{figure}[!h]
\includegraphics[width=\textwidth]{img/java_admin.eps}
\caption{IHM de gestion des promotions}
\end{figure}

\textbf{Les captures suivantes présentent l'interface WEB de l'application}

\begin{center}
\begin{figure}[!h]
\includegraphics[scale=0.15]{img/edt_mobile.eps}
\caption{IHM de visualisation à partir d'un smartphone (EDT d'une promotion)}
\end{figure}
\end{center}

\begin{figure}[!h]
\includegraphics[width=\textwidth]{img/selection_edt_ens.eps}
\caption{IHM de sélection de l'EDT d'un enseignant}
\end{figure}

\begin{figure}[!h]
\includegraphics[width=\textwidth]{img/edt_fixe.eps}
\caption{IHM de visualisation de l'EDT d'une promotion}
\end{figure}

\begin{figure}[!h]
\includegraphics[width=\textwidth]{img/edt_ens.eps}
\caption{IHM de visualisation de l'EDT d'un enseignant}
\end{figure}

\begin{figure}[!h]
\includegraphics[width=\textwidth]{img/edt_salle.eps}
\caption{IHM de visualisation de l'EDT d'une salle}
\end{figure}
